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METHOD FOR CONFIGURING A COMPUTER PROGRAM 

The present invention relates to a method for configuring a computer program including at 
least one functional unit. 

The present invention also relates to a software system for configuring a computer program 
including at least one functional unit. 

Background Information 

Modern computer programs are predominantly programmed in such a way that they are 
useable in as broad a range of application as possible. The range of application is determined 
on one hand by the functionalities made available, which in turn should cover as many user 
desires as possible, and on the other hand by the underlying hardware on which the computer 
program is to run. In this context, the underlying hardware denotes different computer 
systems which are used in different areas, are constructed of different components (e.g., 
processors or bus systems), and/or have different peripherals. 

Different functionalities can result from different conditions of the underlying hardware or 
from different user desires. Adaptation, and therefore specialization, of a computer program 
15 to underlying hardware and to specific user desires includes a so-called configuration of the 
computer pro gram. 

For example, a configuration includes the activation or deactivation of individual functions of 
the computer program, the setting of starting values for certain variables or the preselecting 
and specifying of certain variable types. 

20 It is well-known to declare the variables and functions used in a computer program in a so- 
called header file, and to configure the computer program by changing individual variables or 
function designators in the header file. For example, it is possible to assign a special function 
to a function designator used in the computer program and declared in the header file, 
depending upon a specific configuration. 
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Computer programs are usually created in a so-called high-level programming language, e.g., 
C, C++, Scheme or JAVA. A computer program created in a high-level programming 
language is usually referred to as source code. To permit execution of such a computer 
program on a computer, a so-called machine code must be generated from the source code, 
5 the machine code containing instructions which are executable by the processor of the 

computer. Machine code can be generated by so-called interpretation or compilation of the 
source code. 

Typically, a computer program includes a plurality of functional units. The source code of 
one or more functional units is stored in a data file. A header file is assigned to one or more 
10 such data files. Thus, a computer program is typically made up of a plurality of data files. A 
configuration of such a computer program, which is accomplished by changes within 
individual header files, is therefore very unclear and can often only be accomplished by the 
creator of the source code. In addition, a documentation must be created for all header files, 
which is very painstaking; even the documentation is for the most part very unclear. 

15 To configure a computer program, it is also known to assign it a special functional unit by 
which it is possible to configure the entire computer program, e.g., by altering the values of 
predefined parameters. For example, the functional unit may be launched from within the 
computer program running, and be executed for configuring the computer program. 
However, such a functional unit provided for configuring the computer program only allows 

20 a configuration within predefined range limits. A configuration of the computer program, 
e.g., for adapting the computer program to new hardware or for adapting the computer 
program to new desires of the user is not possible using such a functional unit. Moreover, the 
functional unit used for the configuration must be developed specially for the computer 
program in question, and cannot be used for other computer programs. 

25 Therefore, the object of the present invention is to provide a possibility that allows as clear 
and flexible a computer-program configuration as possible. 

The objective is achieved by a method of the type indicated at the outset, which includes the 
following steps: 

creation of at least one implementation-independent configuration data file 
30 and/or alteration of information filed in the at least one implementation- 

independent configuration data file; 
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automatic set-up and/or automatic update of configuration data, stored in a 
configuration data container, as a function of the information filed in the at 
least one implementation-independent configuration data file; 
automatic generation of at least one implementation-dependent configuration 
5 data file as a function of the configuration data stored in the configuration data 

container; 

automatic configuration of the at least one functional unit as a function of 
information filed in the at least one implementation-dependent configuration 
data file. 

1 0 Summary of the Invention 

Thus, the data determining a configuration is filed independently of an intended, specific 
implementation, in one or more implementation-independent configuration data files. In 
particular, the implementation independence of this configuration data file permits an abstract 
description of the filed information. This makes it possible to file the information relevant for 

15 the configuration of the computer program so that it is particularly easy to read, and therefore 
to markedly simplify the configuration. Because this configuration data file is 
implementation-independent, it is possible in particular to configure the computer program in 
a simple manner so that, for instance, the computer program is executable on a new computer 
system whose exact parameters were not even known yet when the computer program was 

20 created. 

The configuration data container makes it possible to centrally provide all data relevant for a 
configuration. At least one implementation-dependent configuration data file is generated 
automatically with the aid of the configuration data stored in the configuration data container. 
In the implementation-dependent configuration data file, individual or a plurality of 

25 parameter values are put into concrete terms relative to the implementation-independent 

configuration data file. In such a concretization, for example, relative values are replaced by 
absolute values. Specific data types or structures may be assigned to individual values or data 
areas, as well. Consequently, the implementation-dependent configuration data file takes into 
account implementation-dependent properties, such as one or more programming languages 

30 used when programming the source code, or properties of the hardware on which the 
computer program is intended to run. 
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The set-up or the updating of the configuration data container with the aid of the information 
filed in the implementation-independent configuration data files may be carried out using so- 
called scripts, for example. In this context, a script denotes a sequence of instructions which 
are executable by a special computer program. Such special computer programs are AWK or 
5 Perl, for example. These special computer programs may also be used to generate 

implementation-dependent configuration data files from the configuration data stored in the 
configuration data container. 

An essential part of the invention is thus the recognition that the configuration of a computer 
program may be improved decisively by providing between a user (configurator) and the 

10 computer program, an abstract description of the configuration to be implemented in the 
implementation-independent configuration data file, which is taken as the basis of the 
configuration. With the aid of the implementation-independent configuration data file, an 
implementation-dependent configuration data file is automatically created which is then 
utilized for configuring the computer program. The method of the present invention thus 

15 makes it possible to specify the information describing a configuration in an abstract and 
therefore particularly easily readable manner. Moreover, especially high flexibility is 
achieved due to the independence of any implementation details. 

In one advantageous further development of the method, at least one item of dependency 
information, which describes a dependency on at least two configuration data present in the 
20 configuration data container, is automatically generated. The at least one implementation- 
dependent configuration data file is generated as a function of the at least one item of 
dependency information. 

Dependency information may describe, for example, whether the change of one configuration 
parameter has an effect on another configuration parameter. For instance, if a resource is 
25 reserved exclusively for one functional unit, then it is not available to other functional units 
during the execution of the functional unit. Using dependency information, it is possible to 
ascertain which functional units need a specific resource, and therefore cannot run 
simultaneously. Consequently, dependency information may also be used for resource 
management. 

30 In one preferred specific embodiment of the method, a plurality of implementation- 
independent configuration data files is created, and each of the implementation-independent 
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configuration data files is assigned to at least one functional unit. This allows a particularly 
simple configuration, because the configuration parameters filed as information in the 
implementation-independent configuration data files can be found and altered especially 
easily. For example, it is possible to sort the information determining a configuration, thus, 
5 the configuration parameters, according to the functionality influenced by it, or according to 
hardware. Moreover, a particularly simple adaptation of the implementation-independent 
configuration data files to newly added functional units is thereby made possible. In the 
simplest case, a special implementation-independent configuration data file is assigned to a 
newly added functional unit. 

10 A plurality of implementation-dependent configuration data files is advantageously 

generated, and each of the implementation-dependent configuration data files is allocated to 
at least one functional unit. Such a structuring of the implementation-dependent configuration 
data files increases the clarity of the implementation-dependent configuration data files 
generated. If the source code is structured in such a way that one or more functional units are 

15 located in different data files, then an implementation-dependent configuration data file can 
be allocated to each of the data files of the source code. A particularly lucid structuring may 
also be achieved by, in each case, assigning one implementation-dependent configuration 
data file to each implementation-independent configuration data file. 

The at least one implementation-dependent configuration data file is preferably generated as a 
20 function of at least one property of hardware on which an installation of at least one portion 
of the configured computer program is to be made possible. For instance, such a hardware 
property may be the number of processors available or the type and number of sensors 
connected to the hardware. If such hardware properties are taken into account when 
generating the implementation-dependent configuration data files, an especially precise 
25 configuration of the computer program is then possible. Particularly using dependency 
information, it is therefore possible, for instance, to automatically create a configuration 
optimized with regard to execution speed. 

In one preferred specific embodiment, the at least one implementation-dependent 
configuration data file is generated as a function of the result of a plausibility check. For 
30 example, a plausibility check may include a check as to whether a resource needed by a 
functional unit is available at all. 
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The at least one hardware property is preferably used to carry out the plausibility check. It is 
thereby possible to greatly increase the degree of automation, and to achieve a reliable 
configuration of the computer program. For example, if a functional unit provides for an 
acquisition of measured values, it may be checked whether suitable sensors are present and 
5 whether they make available the measuring accuracy demanded. In this case, it is 
conceivable, for instance, that the sensor is configured automatically. 

In a further preferred specific embodiment, a documentation is created automatically. The 
documentation describes the information filed within the at least one implementation- 
independent configuration data file and/or the at least one implementation-dependent 

10 configuration data file. On one hand, documentations automatically generated in this way 
increase the maintainability of the computer program, and on the other hand, permit 
especially easy comprehension of an accomplished configuration. The automatic generation 
of the documentation ensures that it conforms with the actual configuration. If a new 
configuration of the computer program is to be carried out, then with the aid of such a 

15 documentation, it is possible to determine particularly easily which parameter values must be 
changed. 

Preferably, the at least one implementation-independent configuration data file is created in 
an XML-based format. XML (Extensible Markup Language) is a standardized meta language 
which makes it possible to generate structured languages. If the at least one implementation- 

20 independent configuration data file is created in an XML-compliant, structured language, 

then a configuration is facilitated, because such an implementation-independent configuration 
data file can be read particularly well. Moreover, a configuration data file of this kind can 
also be read especially well by machine. In particular, a plurality of software tools exists, 
likewise standardized in part, by which it is possible to edit and process data files created in 

25 an XML-based format. 

In one preferred specific embodiment of the method, as a function of the configuration data, 
it is automatically determined whether a functional unit included by the computer program is 
needed by the computer program, and this functional unit is configured only if the functional 
unit is needed by the computer program. This facilitates an especially rapid configuration, 
30 because only those functional units are actually configured which are really needed in an 
execution of the configured computer program. Furthermore, the configured computer 
program thereby takes up as little storage space as possible, since, for example, a translation 
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of source code into machine code is only brought about for those functional units which are 
actually intended to be used. 

The objective is also achieved by a software system of the type indicated at the outset. In this 
context, the software system has: 

5 at least one implementation-independent configuration data file; 

a configuration data container including configuration data and/or means for 
creating a configuration data container as a function of information filed in the 
at least one implementation-independent configuration data file; 
means for altering and/or reading out configuration data from the 
1 0 configuration data container; 

means for automatically generating at least one implementation-dependent 
configuration data file as a function of configuration data stored in the 
configuration data container; and 

means for automatically configuring the at least one functional unit as a 
15 function of information filed in the implementation-dependent configuration 

data file. 

Preferably, the software system has means for carrying out the method of the present 
invention. 

The implementation of the present invention in the form of a software system is of particular 
20 importance. In this context, the software system is able to run on a computing element, 

particularly on a microprocessor, and is suitable for carrying into effect the method according 
to the present invention. In this case, therefore, the present invention is realized by the 
software system, so that the software system constitutes the present invention in the same 
way as the method for whose execution the software system is suitable. The software system 
25 is preferably stored in a memory element. The memory element may take the form of a 

random access memory, read only memory or flash memory. The memory element may also 
be in the form of a digital versatile disk (DVD), compact disk (CD) or hard disk. 

Brief Description of the Drawing 

Further advantages, features and possible applications of the present invention may be 
30 derived from the following description of exemplary embodiments of the present invention, 
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which are illustrated in the drawing. All of the features described or illustrated here, either 
alone or in any desired combination, constitute the subject matter of the present invention, 
regardless of how they are combined in the patent claims or their antecedent reference, and 
regardless of how they are formulated in the description or illustrated in the drawing. The 
5 figures show: 

Figure 1 a specific embodiment of a software system for carrying out the 

method of the present invention; and 

Figure 2 a schematic flow chart of a specific embodiment of the method 

according to the present invention. 

10 Description of the Exemplary Embodiments 

Figure 1 shows a software system for carrying out the method of the present invention. The 
software system has a plurality of implementation-independent configuration data files 1 . A 
file name is assigned to each configuration data file 1 . For example, the implementation- 
independent configuration data files shown in Figure 1 bear the file names conf_l.xml, 
15 conf_2.xml, conf_3.xml through confn.xml. The file ending .xml indicates that 

implementation-independent configuration data files 1 are in an XML-based format. A text 
file in an XML-based format makes it possible to structure the text file according to 
specifiable rules. Such a structured text file can be read particularly well manually and by 
machine and processed. 

20 Implementation-independent configuration data files 1 are fed to a script 2. Script 2 is in the 
form of a so-called Perl script, for example. Perl is an interpreter language whose syntax is 
based on programming language C, and which uses utility programs made available by the 
specific operating system. 

Using script 2, implementation-independent configuration data files 1 are read, and the 
25 information stored therein is extracted and stored in a configuration data container 3. At the 
same time, possibly existing dependencies with respect to further configuration scripts 4 are 
also determined and stored. 

Further configuration scripts are represented by reference numeral 4. They are likewise in the 
form of Perl scripts. It is equally conceivable that one or more of further configuration scripts 
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4 is an executable computer program (machine code), or exists in another script language, 
e.g., AWK. 

Implementation-dependent configuration data files are denoted by reference numeral 5. For 
example, implementation-dependent configuration data files 5 are coded in the programming 
5 language in which the source code to be configured is also programmed. Such 

implementation-dependent configuration data files are able to be processed by a compiler 6. 

Reference numeral 7 denotes a computer program having a plurality of functional units 8. 

The functioning method of the software system according to the present invention is 
described with reference to the flow chart shown in Figure 2. 

10 The flow chart of a method according to the present invention for configuring a computer 
program shown in Figure 2 starts at a step 100. In a step 101, implementation-independent 
configuration data files 1 are created or altered. Implementation-independent configuration 
data files 1 have the special distinction that, using tfie information stored therein, it is possible 
to describe concrete configuration values or configuration parameters in abstract fashion. For 

15 instance, concrete configuration values may define the measuring range of a sensor module 
for measuring an electric voltage. Illustratively, it is possible to specify a measuring range 
abstractly with the values 3 — 5 volts. However, the implementation-dependent values of the 
measuring range to be generated therefrom, in the manner functional unit 8 to be configured 
expects, may lie between 1 0,000 and 20,000, for example. In this case, a computer-program 

20 functional unit 8 controlling the sensor module would have to be configured using the 

concrete configuration values 10,000 and 20,000, for instance, to permit a measurement in a 
measuring range of 
3-5 volts. 

Implementation-independent configuration data files 1 created or altered in step 101 are 
25 created, for example, in an XML-based format. Such a format makes it particularly easy to 
achieve a lucid structuring of implementation-independent configuration data files 1. This 
increases the readability of implementation-independent configuration data files 1 and 
simplifies the alteration of implementation-independent configuration data files 1, e.g., 
because configuration data to be altered can be quickly found. It is possible to provide only 
30 one implementation-independent configuration data file, even for a particularly large 

computer program requiring a multitude of configuration data for its configuration. In this 
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context, the information filed in implementation-independent configuration data file 1 is able 
to be structured using suitable XML structures. However, it is especially advantageous to 
provide a plurality of implementation-independent configuration data files. For instance, each 
of these implementation-independent configuration data files 1 may be assigned to one or 
5 more functional units 8. It is thereby possible to create or alter the implementation- 
independent configuration data files in a particularly clear manner. In addition, reusability of 
individual implementation-independent configuration data files is thereby increased. This is 
especially advantageous for projects in which individual functional units 8 of the source code 
are also to be reused. 

10 In step 102, configuration data container 3 is set up or updated. This is accomplished by 

processing the instructions listed in script 2. Script 2 first causes independent configuration 
data files 1 to be input. If implementation-independent configuration data files 1 are based on 
a structured format, e.g., an XML-based format, then a syntactic and/or semantic analysis of 
the contents of implementation-independent configuration data files 1 may be carried out 

15 particularly well using script 2. Consequently, errors, for instance, in the specifying of 

configuration data may be recognized. Preferably, the XML-based format of implementation- 
independent configuration data files 1 has a hierarchical structure that is advantageously 
oriented to the structure of functional units 8 themselves, their dependencies and/or their 
thematic closeness. Errors in the set-up of this hierarchical structure, and therefore also in the 

20 set-up of the source code itself may be recognized using script 2. 

Errors found are advantageously handled in step 102. This may be accomplished, for 
example, by the output of error information. It is equally conceivable to use stochastic 
methods to remove errors. 

In step 102, script 2 extracts the configuration data present in implementation-independent 
25 configuration data files 1 and stores it in configuration data container 3. Configuration data 
container 3 may be in the form of a database, for example. It is likewise conceivable to 
realize configuration data container 3 as data structure, provided in a storage area, within the 
software system of the present invention, in so doing, it being ensured that script 2 has 
writing and reading access to the configuration data stored in configuration data container 3. 

30 In a step 103, dependencies are ascertained. For example, one such dependency may describe 
which functional units 8 of the computer program must actually be processed in the case of 
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the present configuration. With the aid of these dependencies, it is possible to decide whether, 
in one of the following steps, it is necessary to generate an implementation-dependent 
configuration data file for a specific functional unit 8 at all. Dependencies may further 
describe which concrete configuration data are dependent on which abstract configuration 
5 data. Thus, it is conceivable that the change of an abstract configuration datum in an 

implementation-independent configuration data file will bring about a change in a plurality of 
concrete configuration data. 

Dependencies may also arise if further scripts 4 on their part alter configuration container 3. 
Thus, the correct activation sequence of scripts 4 must be ascertained and stored. 
10 Dependencies may also describe relationships between one or more hardware components 

and individual configuration data. This makes it possible to recognize, for instance, whether a 
configuration provided is actually executable on specific hardware. 

In step 104, a plausibility check is carried out. In so doing, especially based on the 
dependencies ascertained in step 103, it is checked whether the configuration predefined with 
15 the aid of implementation-independent configuration data files 1 has errors. If this is the case, 
there is a branch back to step 101 in which a change is made in implementation-independent 
configuration data files 1 with the aim of eliminating errors. If no errors are recognized in 
step 104, there is a branching to step 105. 

In step 105, implementation-dependent configuration data files 5 are generated. To that end, 
20 first of all the configuration data stored in configuration data container 3 is retrieved with the 
aid of a script 4 or a plurality of scripts 4. In the present exemplary embodiment, scripts 4 are 
in the form of Perl scripts. Abstract configuration data, stored in particular in configuration 
data container 3, is converted by scripts 4 into concrete configuration data, which is then filed 
in implementation-dependent configuration data files 5. In so doing, preferably the 
25 dependencies ascertained in step 103 are used, as well. 

For example, implementation-dependent configuration data files 5 generated in step 1 05 may 
be header files (file_.h, file_2.h, file_3.h in Figure 1). In the same way, generated 
implementation-dependent configuration data files 5 may also contain source code (file_2.c, 
file k.c in Figure 1). Typically, the concrete configuration data generated by scripts 4 from 
30 the abstract configuration data is realized by value assignments for variables and/or function 
parameters, and as instructions in a programming language. In this context, the programming 
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language corresponds to the programming language in which functional units 8 of computer 
program 7 are coded. For example, if functional units 8 of computer program 7 are coded in 
programming language C**, then the concrete configuration data may be realized by so-called 
#define instructions, for instance, or by the definition of constant variables. Depending on the 
5 configuration data stored in configuration data container 3, it is also possible with the aid of 
scripts 4 to generate functions which assume complex tasks - such as the initialization of 
hardware components, or checking for the presence of individual software components or 
hardware components - and are themselves realized as source code in a higher programming 
language. This source code may then be stored in one or more implementation-dependent 
10 configuration data files (file_2.c, file_k.c in Figure 1). For that purpose, for example, a script 
4 may contain a so-called template, made up, for instance, of instructions in C++, which are 
updated as a function of the configuration data stored in configuration data container 3, and 
are filed in an implementation-dependent configuration data file 5. 

In step 107, functional units 8 of computer program 7 are updated. For example, this may be 
15 accomplished by the automatic call-up of a compiler 6 which translates functional units 8, 
existing in a source code, into a machine code. To that end, compiler 6 reads in 
implementation-dependent configuration data files 5 and controls the generation of the 
machine code as a function of the concrete configuration data filed in implementation- 
dependent configuration data files 5. It is also conceivable that one or more functional units 8 
20 already exist in machine code. In this case, the compiler may, for instance, translate the 

source code (file_2.c, file_k.c in Figure 1), generated by scripts 4, into machine code, taking 
the header files (file_l.h, file_2.h, file_3.h) into account, and link the machine code thus 
translated to the machine code representing functional units 8 with the aid of a so-called 
linker assigned to compiler 6. 

25 The method ends in step 108. In this step, computer program 7 is configured in such a way 
that the concrete configuration data, filed in the implementation-independent configuration 
data files, is taken into account in the machine code generated. 

Of course, it is possible for script 2 and/or scripts 4 to be written in another script language, 
or to be developed as executable programs. 
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The execution steps shown in Figure 2 may, of course, vary, and the processing sequence 
may be partially altered. Thus, it is conceivable for plausibility check 104 to be carried out by 
one or more of scripts 4. 

In particular, the method may also start out from one or more implementation-independent 
5 configuration data files; have one or more scripts 2 that, for instance, are executed 

consecutively; have one or more scripts 4, each generating one or more implementation- 
dependent configuration data files 5; and of course, computer program 7 may have one or 
more functional units 8. Using the method of the present invention, it is possible, in 
particular, to recognize whether one or more of functional units 8 actually come to be used in 

10 the configuration predefined by the implementation-independent configuration data files. If 
this is not the case, it can be recognized by a software tool (not shown), assigned to 
configuration data container 3. This makes it possible that such a functional unit 8 is not 
configured, and with the aid of implementation-dependent configuration data files 5, 
compiler 6 is induced not to import functional unit 8 into the machine code to be generated. 

15 The method of the present invention may thereby be carried out particularly rapidly. The 

machine code generated by a computer program, which was configured using the method of 
the present invention, may be especially compact and therefore is able to save memory space. 

There is the possibility of script 2 itself already bringing about the generation of one or a 
plurality of implementation-dependent configuration data files 5. The method of the present 
20 invention may thereby be carried out particularly rapidly. For example, this may be 

advantageous for abstract configuration data that has no dependencies and differs from the 
concrete configuration data. 
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